\section{Context} \label{sec:context}
In this work, we assume that the evaluation of access control follows the standard access control PEP-PDP architecture. In this architecture, the PDP evaluates accesses and the PEPs enforce decisions
taken by the PDP. A PEP-PDP architecture centralizes the location where the policy is evaluated. Therefore, it simplifies policy update and management.

In the context of a Java application, a PEP typically corresponds to a method $M_{p}$ that is encapsulated in the business logic. Every $M_{p}$ is generally associated with a set of services.
Once a given service is requested, $M_{p}$ is triggered and the PDP is called. The PDP evaluates the current access control policy and allows or denies access accordingly. The decision taken by
the PDP is enforced by the PEP.

\begin{figure}[t]
\begin{center}
\includegraphics[width=9cm,height=6.5cm]{pepsconfiguration}
\caption{Possible PEPs Configurations}
\label{Possible PEP Configurations}
\end{center}
\end{figure}

PEPs are typically organized according to two typical configurations. These configurations are shown in Figure \ref{Possible PEP Configurations} and may be described as follows.
\begin{itemize}
\item Access is enforced by a PEP on the callee's (the service) side: In this case, the PEP is encapsulated in the service implementation. Access control is
centralized since enforcement mechanisms reside inside the implementation code of the service itself.
Configuration A in Figure \ref{Possible PEP Configurations} illustrates this scenario.
\item Access is enforced by a PEP on the caller's (the client) side like shown in Configuration B of Figure \ref{Possible PEP Configurations}: In such configuration, controls are decentralized
since the PEP is located at the application level of the client side.
\end{itemize}
Within an application, PEPs are typically organized according to one of the configurations above or using a mix of the two configurations depending on the security requirements. It may also occur that some PEPs are mis-implemented or missing.
The lack of documentation of PEPs is therefore problematic since it is difficult to say how and where PEPs are located inside an application's code.
Moreover, the lack of documentation about the mapping between PEPs in the application code and security rules may compromise the secure evolution of the policy whenever a policy update is needed.

